Closed
Bug 597590
Opened 14 years ago
Closed 14 years ago
GL context destroyed on every scroll started event in SurfaceBufferOGL
Categories
(Core Graveyard :: Widget: Qt, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 592464
People
(Reporter: romaxa, Unassigned)
References
Details
Attachments
(2 files, 1 obsolete file)
15.40 KB,
text/plain
|
Details | |
24.01 KB,
patch
|
Details | Diff | Splinter Review |
run MOZ_QT_GRAPHICSSYSTEM=native MOZ_ACCELERATED=1 ./fennec -graphicssystem native -url about:license in console you will see : XXX stub Initializing context 0x4a522ca0 surface 0x4a9b3000 on display 0x2 Destroying context 0x4a953f70 surface 0x4c6e4c00 on display 0x2 XXX stub .... Initializing context 0x4a953f70 surface 0x4c6e4c00 on display 0x2 Destroying context 0x4a522ca0 surface 0x4a9b3000 on display 0x2 XXX stub while scrolling. Something wrong here
Reporter | ||
Comment 1•14 years ago
|
||
Reporter | ||
Comment 2•14 years ago
|
||
Ok, tested on latest m-c: 6ec3a45f4309, and problem already fixed there.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 3•14 years ago
|
||
hm... no I was running without arg flags, and CreateOffscreenSurface was creating Image surface instead of X.... (because of raster is default system.) problem still reproducible if -graphicssystem native cmd arguments provided.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 4•14 years ago
|
||
Ok, we have currently 2 different paths: 1) BasicBufferOGL, which is creating ImageSurface and has own ::BeginPaint implementation. and that implementation recycle existing buffer. 2) SurfaceBufferOGL, which is using ThebesLayerBuffer::BeginPaint implementation... Problem of ThebesLayerBuffer::BeginPaint implemetation is that it is always create new Buffer when we start new scrolling, and this is bad: a) for non-accelerated fennec, because we re-create new buffer and allocate new memory on each scroll start b) for accelerated fennec it is re-creating all the time Pixmap surface and rebounding textures.... I think we should use the same BeginPaint implementation in all cases, and have it universally optimized for GL and NON-GL rendering
Reporter | ||
Updated•14 years ago
|
Summary: GL context destroyed on every scroll finished event in Qt port → GL context destroyed on every scroll started event in SurfaceBufferOGL
> Problem of ThebesLayerBuffer::BeginPaint implemetation is that it is always
> create new Buffer when we start new scrolling
What do you mean? ThebesLayerBuffer::BeginPaint tries to reuse the same buffer when scrolling.
Reporter | ||
Comment 6•14 years ago
|
||
> What do you mean? ThebesLayerBuffer::BeginPaint tries to reuse the same buffer > when scrolling. It does, but it always create new similar surface when user start new scrolling (from static state) I found that vlad's patch from bug 596784, make situation a bit better, I think we should have one scroll/buffer update logic for optimized and non-optimized GL path.
Depends on: 596784
(In reply to comment #6) > It does, but it always create new similar surface when user start new scrolling > (from static state) When you scroll the viewport of the toplevel content document we should not be creating new surfaces. Is that what you're testing? If you're scrolling an overflow:auto element, you will see that. That is nsGfxScrollFrame switching from "inactive" to "active" scrolling.
Reporter | ||
Comment 8•14 years ago
|
||
Ok, problem in bad implemented CreateTextureImage... which is creating new GLContext for each TextureImage...
Reporter | ||
Comment 9•14 years ago
|
||
Implement common rendering path for EGL backend, make it works using slow GL Text2DImage upload. Also added support for BackingSurface and basic BindText Image. Still not clear for canvas context
Reporter | ||
Comment 10•14 years ago
|
||
Attachment #481498 -
Attachment is obsolete: true
We're still using a heavyweight thing (a GL context) when we just want a lightweight texture binding from a pixmap. We need to just implement -that-, in gfxXlibSurface, in conjunction with whatever support is needed in the EGL backend to call the EGL functions for binding such a texture for drawing.
Reporter | ||
Comment 12•14 years ago
|
||
ok, then it is dup for 592464
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•